This is a big change, and I really feel like I might be missing something re: safety, so it'd be great if anybody wants to take a look at it and tell me how I've inevitably missed some crucial safety aspect.

If this is a viable strategy, though, it fixes #40 and.. more or less #56 as well.

A key realization for me was that everywhere that I've ever NEEDED to give a !Send type to Lua, it has always been some sort of lock, like RwLockReadGuard etc. These also always need some sort of mechanism to manually expire them and ensure that they don't leak out, so in this way, Lua::scope does double duty by making it safe for Lua to be Send, as well as making the expiration mechanism built in. It doesn't seem like a feature, but it is.

One thing that's not tested here that should be tested is accessing expired values through rlua::Function and rlua::AnyUserData. I believe the behavior will be that if Function is called, it will just always error, and AnyUserData will behave as though it is not any type at all.

I've slept on it, and discussed it within chucklefish, and I still feel pretty good about this change. We, at least, can't figure out a way to trick it into unsafety (famous last words).

I think I'm going to go ahead and merge this into master, but I'd still like to discuss it before doing another major rlua release.

It is potentially the most annoying API change yet because of the new requirement of userdata to be Send, I don't really have a good sense of the amount of pain this will cause.

Well, I merged this, but I actually screwed up the lifetimes in Lua::scope, and it's possible to reference things that don't live long enough.

I'm currently staring that the crossbeam crate trying to figure out the correct technique.